Fix order-dependent deletion for superset value lists (#260) - #263

Hi @Pybsama
Thank you for the PR, will review the content in the coming days.

Thanks @Pybsama for your contribution. This is a careful fix, and the test design is strong.

• Your five tests cherry-picked onto unmodified main fail 4/5, exactly as they should (the 5th, testIssue260SupersetDeletePreservesPriorKeyCandidates, correctly passes on main — it pins behavior a naive fix would break).
• testIssue260TerminalSupersetDoesNotResetPriorKeyCandidates is a nice catch beyond what Machine.deleteRule with a superset value list can silently no-op depending on value order #260 documented: on main, the empty-set re-init at a terminal key over-deletes — it removes registrations reachable only via other first-key values. Your fix closes both directions.
• Full mvn verify on your branch is green (772 tests), and the five new tests are stable across 20 repeated runs.
• The approach matches the direction we settled in Fix Machine.deleteRule isolation for shared wildcard sub-patterns (#255) #256: values within a key are OR semantics, so every value/NameState alternative is evaluated from the candidates inherited from the preceding keys. Unifying the single- and multi-NameState paths is a welcome simplification, and I confirmed the wildcard teardown guard is unchanged and nothing reachable from the matching path is touched (so your no-benchmark-regression conclusion holds).

Two changes I'd like before merge:

1. Simplify the new flag away. At every call site candidateSubRuleIdsInitialized equals keyIndex != 0 (deletePatternRule passes (0, false); the only recursion passes (keyIndex + 1, true)). Carrying the same fact twice through the walk invites drift at a future call site. Please drop the parameter from both signatures and test keyIndex == 0 at the initialization branch — zero behavior change, smaller diff. While you're there: the new HashSet<>(candidateSubRuleIds) at the recursion call is now a redundant defensive copy (post-change, deleteStep never mutates its parameter — each branch takes its own copy), so it can pass the set directly.

2. Pin the later-key continuation with a test that actually deletes. The "empty branch is confined to that branch" behavior is only exercised-with-deletion at the first key. Both later-key tests use delete lists that cover no stored sub-rule, so they can't distinguish "continued past the empty branch" from "aborted the key". Please add a variant where the second value at a later key legitimately deletes, e.g.:

   • add r1 {"a":["one"],"b":["right"]} and other {"a":["one"],"b":["missing"]}
   • delete r1 with {"a":["one"],"b":["missing","right"]} in both value orders
   • assert r1 is gone, other still matches, and the machine is empty after deleting other.

Optionally polish these:

• A short comment on why withAdditionalNameStateReuse(true) is load-bearing in the two later-key tests (it funnels a key's values into one shared NameState, which is what makes the foreign patterns findable there).
• The new comment's "rather than consuming another branch's result" describes the old behavior; ending at the positive statement reads cleaner.
• A sentence in the deletePatternRule javadoc stating the now-guaranteed semantics (values that reach no rule are skipped; the outcome doesn't depend on value order within a key) — Machine.deleteRule with a superset value list can silently no-op depending on value order #260 existed exactly because this was ambiguous.
• The trailing-blank-line removal at the end of GenericMachine.java is unrelated to the fix; restoring it keeps the diff scoped.

When you've made the changes, please mark the PR ready for review and we can get this formally reviewed.

Generative AI Assisted Review

Addressed the requested changes and marked the PR ready for review:

• Rebased the single fix commit onto current main (a356c6f).
• Removed candidateSubRuleIdsInitialized, derived initialization from keyIndex == 0, and passed the candidate set directly into recursion.
• Added the later-key deletion regression for both [missing,right] and [right,missing], preserving the other rule and confirming final machine teardown.
• Added the NameState-reuse rationale, documented order-independent value semantics, made the branch comment positive, and restored the unrelated trailing blank line.

Fresh verification on JDK 21:

• Issue260 tests: 6 passed
• MachineTest: 98 passed
• mvn verify: 779 passed; Checkstyle and SpotBugs clean
• Benchmarks#CL2*: 2 passed

Current head: d8e4af7.